시스템 엔지니어링 V-모델

2025-11-28, G30DR

1. 서론: 복잡성의 시대와 시스템 엔지니어링의 철학

현대 사회를 지탱하는 기술적 기반은 더 이상 단일한 기계 장치나 단순한 소프트웨어 프로그램으로 설명될 수 없다. 자율주행 자동차, 차세대 전투기, 위성 통신망, 스마트 그리드 등 우리가 마주하는 시스템은 하드웨어, 소프트웨어, 네트워크, 그리고 인간의 상호작용이 다차원적으로 얽힌 ’거대 시스템(System of Systems)’으로 진화하였다.1 이러한 시스템은 구성 요소들의 단순한 합보다 더 큰 기능을 발휘하는 창발적 특성(Emergent Properties)을 가지며, 동시에 예측 불가능한 실패의 위험성을 내포하고 있다.

시스템 엔지니어링(Systems Engineering)은 이러한 복잡성을 통제하고, 이해관계자의 요구사항을 성공적인 운영 시스템으로 실현하기 위해 고안된 학제 간 접근 방식이다.1 시스템 엔지니어링의 핵심은 전체론적 사고(Holistic Thinking)를 바탕으로 문제를 정의하고, 해결책을 설계하며, 그것이 의도한 대로 작동하는지 입증하는 과정에 있다. 이 과정에서 **V-모델(V-Model)**은 단순한 프로젝트 관리 도구를 넘어, 엔지니어링 사고의 논리적 흐름을 시각화하고 구조화하는 가장 강력하고 보편적인 프레임워크로 자리 잡았다.2

본 보고서는 V-모델의 역사적 기원부터 그 구조적 정교함, 검증(Verification)과 확인(Validation)의 철학적·실무적 차이, 그리고 자동차(ISO 26262) 및 항공우주(DO-178C) 등 안전 필수(Safety-Critical) 산업에서의 구체적인 적용 사례를 망라하여 분석한다. 나아가 애자일(Agile) 방법론의 대두에 따른 V-모델의 위기론과 이에 대한 대응으로서의 하이브리드 모델, 그리고 모델 기반 시스템 엔지니어링(MBSE)으로의 진화 방향을 심도 있게 고찰함으로써, 현대 공학에서 V-모델이 갖는 불변의 가치와 미래적 함의를 규명하고자 한다.

2. V-모델의 역사적 기원과 진화: 필연적 탄생

V-모델은 특정 개인의 발명품이라기보다는, 20세기 후반 급격히 복잡해지는 공학 프로젝트를 관리하기 위한 시대적 요구와 필연의 산물이었다. 그 기원은 냉전 시대의 군비 경쟁과 우주 개발이라는 거대한 역사적 맥락 속에 위치한다.

2.1 독일과 미국의 동시 다발적 발전과 수렴

흥미롭게도 V-모델의 개념은 1980년대 후반, 대서양을 사이에 둔 독일과 미국에서 서로 독립적이면서도 동시에 구체화되었다.4 이는 당시 선진 공학국들이 공통적으로 직면했던 ’시스템 복잡성의 위기’를 방증한다.

독일의 경우, 뮌헨 인근 오토브룬(Ottobrunn)에 위치한 IABG가 연방 국방기술조달청(Federal Office for Defense Technology and Procurement)과 협력하여 V-모델을 개발하였다.4 독일 국방부의 주도로 진행된 이 프로젝트는 정부 조달 사업의 투명성을 확보하고, 개발 프로세스를 표준화하여 산출물의 품질을 보증하려는 명확한 행정적, 공학적 목적을 가지고 있었다. 이는 독일 특유의 체계성과 엄격함이 반영된 결과로, 이후 독일 V-모델(Das V-Modell)이라는 국가 표준으로 발전하게 된다.

반면 미국에서는 항공우주 및 위성 시스템 개발의 현장에서 V-모델이 태동하였다. 1991년 국립 시스템 엔지니어링 협의회(NCOSE, 현재의 INCOSE) 회의록에 따르면, 미국의 V-모델은 하드웨어와 소프트웨어, 그리고 인간의 상호작용이 필수적인 위성 시스템을 다루기 위해 개발되었다.4 특히 휴즈 항공(Hughes Aircraft)의 기업 문화가 결정적인 영향을 미쳤다. 휴즈 항공은 1963년부터 ’STOP(Sequential Thematic Organization of Publications)’이라는 방식을 통해 텍스트와 분석을 다차원적 이미지로 결합하는 문화를 가지고 있었는데, 이러한 시각적 구조화 역량이 복잡한 엔지니어링 프로세스를 ’V’라는 직관적인 형태로 형상화하는 데 기여한 것으로 분석된다.4

2.2 폭포수 모델의 한계와 추적성의 시각화

V-모델의 등장은 기존 소프트웨어 개발 방법론인 폭포수 모델(Waterfall Model)의 한계를 극복하려는 시도에서 비롯되었다. 폭포수 모델은 요구사항 분석에서 유지보수까지 물이 흐르듯 순차적으로 내려가는 선형적 구조를 가졌다.5 그러나 이 모델은 테스트 단계에서 결함이 발견되었을 때, 그 원인이 되는 상위 단계(요구사항이나 설계)로 되돌아가는 비용과 절차가 지나치게 복잡하다는 치명적인 단점이 있었다.

V-모델은 폭포수 모델의 순차적 흐름을 유지하되, 구현(Implementation/Coding) 단계를 기점으로 프로세스를 위로 꺾어 올림으로써 ‘V’ 자 형태를 완성했다.6 이 기하학적 변형은 단순한 시각적 유희가 아니다. 이는 V의 왼쪽(개발 및 정의 단계)과 오른쪽(통합 및 검증 단계)이 완벽한 대칭을 이루며, 각 개발 단계가 그에 상응하는 테스트 단계와 직접적으로 연결된다는 **‘추적성(Traceability)’**의 개념을 물리적으로 구현한 혁명적 발상이었다.7 즉, V-모델은 “테스트는 개발의 마지막 단계가 아니라, 개발의 시작과 동시에 계획되어야 한다“는 철학을 내포하고 있다.5

2.3 국방 표준의 정립과 확산

미 국방부(DoD)는 시스템 엔지니어링 프로세스를 표준화하는 데 앞장섰다. 1969년 제정된 MIL-STD-499와 1974년의 MIL-STD-499A는 임무 요구사항 분석, 기능 분석, 할당, 통합이라는 시스템 엔지니어링의 핵심 프로세스를 정의하며 V-모델의 이론적 토대를 마련하였다.8

MIL-STD-499 시리즈는 정부와 계약업체(Contractor) 간의 의사소통 기준을 수립하고, 복잡한 무기 체계 개발 시 발생할 수 있는 리스크를 관리하기 위한 필수 지침이었다. 비록 1990년대 획득 개혁(Acquisition Reform)의 일환으로 MIL-STD-499B가 공식 발행되지 못하고 민간 표준(EIA 632, IEEE 1220 등)으로 전환되었으나, 이 과정에서 정립된 ’요구사항 분해(Decomposition)’와 ’시스템 통합(Integration)’의 대칭적 구조는 오늘날 모든 V-모델 변형의 원형이 되었다.9

3. V-모델의 구조적 해부학: 분해와 통합의 대칭성

V-모델은 시간의 흐름과 추상화 수준이라는 두 가지 축을 기반으로 시스템 생명주기를 입체적으로 조망한다. 가로축은 프로젝트의 시간적 진행(왼쪽에서 오른쪽)을 의미하며, 세로축은 추상화의 수준(위쪽의 고수준 추상화에서 아래쪽의 구체적 구현)을 나타낸다.6

graph TD
%% 스타일 정의
classDef left fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
classDef right fill:#fff3e0,stroke:#e65100,stroke-width:2px;
classDef bottom fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px;
classDef title fill:none,stroke:none,font-size:16px,font-weight:bold;

%% 제목
Title[표준 시스템 엔지니어링 V-모델]:::title

%% 좌측 윙: 명세와 분해
subgraph Left_Wing [좌측: 명세와 분해 Problem Space]
direction TB
URS[사용자 요구사항 분석]:::left
SRS[시스템 요구사항 및 아키텍처]:::left
DD[상세 설계]:::left
end

%% 우측 윙: 통합과 검증
subgraph Right_Wing [우측: 통합과 검증 Solution Space]
direction TB
AT[인수 테스트 Acceptance]:::right
ST[시스템 테스트 System Test]:::right
IT[통합 테스트 Integration]:::right
UT[단위 테스트 Unit Test]:::right
end

%% 하단: 구현
subgraph Implementation [꼭짓점: 구현]
Code[구현 / 코딩 / 하드웨어 제작]:::bottom
end

%% 프로세스 흐름 (실선)
URS --> SRS
SRS --> DD
DD --> Code
Code --> UT
UT --> IT
IT --> ST
ST --> AT

%% 추적성 및 검증 관계 (점선 - 수평적 연결)
URS -.->|검증: 올바른 제품인가? Validation| AT
SRS -.->|검증: 요구사항 충족? Verification| ST
SRS -.->|인터페이스 확인| IT
DD -.->|로직 확인 Verification| UT

%% 레이아웃 조정 (좌우 대칭 느낌을 주기 위한 보조 링크 - 실제로는 보이지 않게 설정 가능하나 Mermaid에서는 순서로 제어)

3.1 좌측 윙: 명세와 분해 (Specification and Decomposition)

V-모델의 왼쪽 날개는 문제 공간(Problem Space)에서 해결책 공간(Solution Space)으로 내려가는 과정이다. 이는 시스템 엔지니어링의 핵심 원칙인 ’분할 정복(Divide and Conquer)’을 체계적으로 수행하는 단계들로 구성된다.

3.1.1 사용자 요구사항 분석 (User Requirements Analysis)

모든 엔지니어링 활동의 시발점은 이해관계자의 니즈를 파악하는 것이다. 이 단계에서는 기술적 용어가 아닌 사용자의 언어로 “시스템이 무엇을 달성해야 하는가(What)“를 정의한다.6 이해관계자의 목표, 운영 개념(ConOps), 성공 기준을 수립하며, 이는 시스템이 해결해야 할 문제의 본질을 규정한다.2 이 단계의 산출물인 사용자 요구사항 명세서(URS)는 V-모델 우측 최상단의 ’인수 테스트’와 직접 연결되어, 프로젝트의 최종 성공 여부를 판단하는 기준이 된다.

3.1.2 시스템 요구사항 및 아키텍처 설계 (System Requirements & Architecture)

사용자의 모호한 요구사항을 엔지니어링 언어로 변환하는 단계이다. 시스템이 갖추어야 할 기능적(Functional) 요구사항과 성능, 보안, 신뢰성 등 비기능적(Non-functional) 요구사항을 명확히 정의한다. 또한, 시스템 아키텍처 설계를 통해 전체 시스템을 하위 서브시스템(Subsystem)이나 구성 요소(Component)로 나누고, 이들 간의 인터페이스를 정의한다.2 이 단계는 시스템의 골격을 형성하는 과정이며, 우측의 ‘시스템 테스트’ 단계에서 검증된다.

3.1.3 상세 설계 (Detailed Design)

시스템 아키텍처를 바탕으로 각 모듈, 유닛, 부품의 내부 로직과 물리적 형상을 설계한다. 소프트웨어의 경우 알고리즘, 데이터 구조, 클래스 다이어그램이 작성되며, 하드웨어의 경우 회로도, PCB 레이아웃, 기구 설계 도면이 생성된다.5 상세 설계는 구현을 위한 직접적인 지침서가 되며, 우측의 ‘통합 테스트’ 및 ‘단위 테스트’ 계획의 기초 자료가 된다.

3.2 V의 꼭짓점: 구현 (Implementation)

V-모델의 최하단, 즉 꼭짓점에서는 설계된 내용이 실제 물리적 실체나 코드로 구현된다. 소프트웨어 코딩, 하드웨어 제작 및 조립이 이 단계에서 이루어진다.2 V-모델의 관점에서 구현 단계는 전체 프로세스의 중심이 아닌, 좌측의 설계 의도가 우측의 검증 대상으로 전환되는 변곡점에 불과하다. 이는 “코딩이 전부“라는 개발자 중심의 사고에서 벗어나, 전체 시스템 생명주기 관점을 갖게 하는 중요한 구조적 특징이다.

3.3 우측 윙: 통합과 검증 (Integration and Verification)

V-모델의 오른쪽 날개는 구현된 구성 요소들을 조립하고, 좌측 단계에서 정의된 요구사항과 일치하는지 확인하며 거슬러 올라가는 과정이다.

3.3.1 단위 테스트 (Unit Testing)

가장 낮은 수준의 검증 활동으로, 구현된 최소 단위(모듈, 함수, 클래스)가 상세 설계 명세대로 정확히 동작하는지 확인한다.6 주로 화이트박스 테스트(White-box Testing) 기법이 사용되며, 코드의 내부 로직, 분기, 경로 등을 정밀하게 검사한다. 이는 상세 설계 단계와 대칭을 이루며, 개발자가 직접 수행하는 경우가 많다.

3.3.2 통합 테스트 (Integration Testing)

개별적으로 검증된 모듈들을 결합하여 상호작용을 검증한다. 이 단계의 핵심은 모듈 간의 인터페이스(Interface)와 데이터 흐름이 아키텍처 설계 단계에서 정의된 대로 작동하는지 확인하는 것이다.6 빅뱅(Big Bang) 방식보다는 상향식(Bottom-up)이나 하향식(Top-down) 통합이 선호되며, 시스템의 뼈대가 제대로 연결되었는지를 판단한다.

3.3.3 시스템 테스트 (System Testing)

통합된 전체 시스템이 시스템 요구사항 명세서(SRS)를 충족하는지 검증한다. 기능적 요구사항뿐만 아니라 성능, 스트레스, 보안, 회복성 등 비기능적 속성까지 포괄적으로 테스트한다.6 이 단계는 주로 독립적인 테스트 팀(QA)에 의해 수행되며, 시스템이 기술적으로 완성되었는지를 판별한다. 블랙박스 테스트(Black-box Testing)가 주를 이룬다.

3.3.4 인수 테스트 (Acceptance Testing)

V-모델의 마지막 단계로, 최종 사용자가 직접 참여하여 시스템을 인수할지 여부를 결정한다. 사용자 요구사항 문서(URS)를 기반으로 실제 운영 환경(또는 그와 유사한 환경)에서 시스템이 비즈니스 목적을 달성하고 사용자의 니즈를 만족시키는지 확인한다.6 알파 테스트, 베타 테스트 등이 이에 포함된다.

3.4 데이터로 보는 V-모델 단계별 비교

아래 표는 V-모델의 좌측 개발 단계와 우측 테스트 단계의 상호 관계를 요약한 것이다.

개발 단계 (Left Side)	주요 활동 및 산출물	상응하는 테스트 단계 (Right Side)	검증 대상 및 목표	주요 테스트 기법
요구사항 분석	사용자 니즈 파악, URS 작성	인수 테스트	사용자 요구사항 충족 여부, 비즈니스 가치 확인	UAT, 알파/베타 테스트
시스템 설계	기능/비기능 요구사항 정의, 아키텍처 설계	시스템 테스트	전체 시스템의 기능 및 성능, 신뢰성 검증	기능 테스트, 성능 테스트, 부하 테스트
상세 설계	모듈/컴포넌트 내부 로직 설계, 인터페이스 정의	통합 테스트	모듈 간 인터페이스, 데이터 흐름, 상호작용 검증	인터페이스 테스트, API 테스트
구현 (코딩)	소스 코드 작성, 하드웨어 제작	단위 테스트	개별 모듈의 로직 정확성, 코드 표준 준수	정적 분석, 화이트박스 테스트

4. 검증(Verification)과 확인(Validation)의 변증법적 고찰

V-모델을 이해하는 데 있어 가장 중요하면서도 혼동하기 쉬운 개념이 바로 검증(Verification)과 확인(Validation)이다. 시스템 엔지니어링에서 이 두 용어는 엄격히 구분되며, V-모델의 우측 윙을 지탱하는 두 가지 다른 철학적 기둥이다.13

graph TD
%% 노드 스타일
classDef actor fill:#fce4ec,stroke:#880e4f;
classDef doc fill:#e3f2fd,stroke:#0d47a1;
classDef product fill:#e8f5e9,stroke:#1b5e20;

User((사용자/이해관계자)):::actor
Spec[명세서 / 설계도면 / 규격]:::doc
Product[실제 구현된 시스템/제품]:::product

%% 흐름
User --"1: 요구사항 정의 (Needs)"--> Spec
Spec --"2: 개발 및 구현 (Build)"--> Product

%% 검증과 확인 루프
Product --"3: 검증 (Verification)<br>'제품을 명세대로 만들었는가?'<br>(Right Product?)"--> Spec
Product --"4: 확인 (Validation)<br>'사용자가 원하는 제품인가?'<br>(Product Right?)"--> User

%% 추가 설명
subgraph Concept ["차이점 (The Sandwich Analogy)"]
Ver_Note["검증: 레시피대로 햄과 빵이 들어갔는가?"]
Val_Note["확인: 샌드위치가 맛이 있는가?"]
end

4.1 개념적 정의와 차이: “Right Product” vs “Product Right”

검증 (Verification): “우리가 제품을 올바르게 만들고 있는가? (Are we building the product right?)”
초점: 규정 준수(Compliance)와 일관성(Consistency).
활동: 설계 도면, 명세서, 코딩 표준 등 사전에 정의된 요구사항과 개발 산출물이 일치하는지를 확인하는 과정이다.13
성격: 주로 정적 분석(리뷰, 인스펙션)과 낮은 수준의 동적 테스트(단위 테스트)를 포함하며, 내부적인 공학적 무결성을 증명하는 데 집중한다.15 이는 객관적인 기준이 존재하므로 자동화가 용이한 편이다.
확인 (Validation): “우리가 올바른 제품을 만들고 있는가? (Are we building the right product?)”
초점: 사용자 만족(Satisfaction)과 유효성(Utility).
활동: 완성된 제품이 의도된 사용 환경에서 사용자의 실제 니즈를 해결하고 가치를 제공하는지를 확인하는 과정이다.13
성격: 최종 제품을 실제와 유사한 환경에서 구동하는 동적 테스트가 주를 이루며, 주관적인 사용자 경험이 평가 기준이 될 수 있다.

4.2 실례를 통한 심층 분석

4.2.1 일상적 비유: 샌드위치 (The Sandwich Analogy)

이해를 돕기 위해 샌드위치 주문 상황을 가정해보자.17

요구사항: “햄, 토마토, 통밀빵을 사용하여 샌드위치를 만들어라.”
검증(Verification): 완성된 샌드위치를 분해하거나 관찰하여 “햄이 들어갔는가?”, “토마토가 있는가?”, “빵이 통밀인가?“를 체크리스트와 대조하는 행위이다. 레시피(명세서) 준수 여부를 따진다.
확인(Validation): 주문자인 어머니가 샌드위치를 먹어보고 “맛이 있는가?”, “배가 부른가?”, “이것이 내가 원하던 그 맛인가?“를 판단하는 행위이다. 만약 재료는 정확했으나 맛이 형편없다면, 검증은 통과했으나 확인은 실패한 것이다.

4.2.2 자동차 산업의 사례: ABS 시스템

검증: ABS 제어 유닛(ECU)의 소프트웨어가 설계 명세서대로 특정 감속도(g)에서 솔레노이드 밸브를 10ms 간격으로 개폐하는지 테스트 벤치에서 확인한다. 또한, 소스 코드가 MISRA C 코딩 규칙을 준수했는지 정적 분석 도구로 확인한다.18
확인: 실제 차량을 스웨덴의 혹한기 테스트 트랙(Winter Proving Ground)으로 가져가 빙판길에서 급제동을 실시한다. 이때 차량이 스핀하지 않고 조향성을 유지하며 멈추는지, 운전자가 안전함을 느끼는지 평가한다.20 시뮬레이션에서 완벽했던 로직도 실제 눈길의 불규칙한 마찰 계수 앞에서는 무용지물이 될 수 있다. 따라서 ’확인’은 시뮬레이션이 아닌 실세계(Real World)에서의 검증을 요구한다.

4.3 V-모델에서의 위치

일반적으로 V-모델의 우측 하단부(단위 테스트, 통합 테스트)는 **검증(Verification)**의 성격이 강하며, 우측 상단부(시스템 테스트, 인수 테스트)로 갈수록 **확인(Validation)**의 비중이 높아진다.22 그러나 엄밀한 시스템 엔지니어링 관점에서는 각 단계마다 검증과 확인이 반복된다(Verification Loop & Validation Loop). 예를 들어, 요구사항 정의 단계에서도 “이 요구사항이 사용자의 의도를 제대로 반영했는가?“를 확인하는 요구사항 검증(Requirements Validation)이 수행되어야 한다.11

5. 자동차 산업에서의 V-모델: ISO 26262 표준의 적용

V-모델은 단순한 이론을 넘어, 사람의 생명을 다루는 안전 필수(Safety-Critical) 산업에서 법적, 기술적 규제를 준수하기 위한 중추적인 프레임워크로 기능한다. 자동차 기능 안전 국제 표준인 ISO 26262는 V-모델을 표준의 뼈대로 채택하고 있다.23

flowchart TD
%% 스타일
classDef part3 fill:#fff9c4,stroke:#fbc02d;
classDef part4 fill:#e1f5fe,stroke:#0288d1;
classDef part56 fill:#f3e5f5,stroke:#7b1fa2;

subgraph Part3 [Part 3: 개념 단계 Concept Phase]
Item[아이템 정의]:::part3 --> HARA[HARA 위험원 분석]:::part3
HARA --> SafetyGoal[안전 목표 설정 Safety Goals]:::part3
end

subgraph Part4 [Part 4: 시스템 레벨 System Level]
TSR[기술적 안전 요구사항 도출]:::part4 --> Arch[시스템 아키텍처 설계 및 할당]:::part4
Arch --> SysInt[시스템 통합 및 검증]:::part4
SysInt --> SysVal[안전성 확인 Validation]:::part4
end

subgraph HW_SW [Part 5 & 6: 하드웨어/소프트웨어 상세 개발]
direction TB
subgraph SW [Part 6: Software]
SW_Req[SW 요구사항]:::part56 --> SW_Arch[SW 아키텍처]:::part56
SW_Arch --> SW_Unit[SW 유닛 구현]:::part56
SW_Unit --> SW_Test[SW 테스트 & 검증]:::part56
end
subgraph HW [Part 5: Hardware]
HW_Req[HW 요구사항]:::part56 --> HW_Design[HW 설계]:::part56
HW_Design --> HW_Fab[HW 제작]:::part56
HW_Fab --> HW_Test[HW 테스트 & 검증]:::part56
end
end

%% 연결
SafetyGoal --> TSR
Arch --> SW_Req
Arch --> HW_Req
SW_Test --> SysInt
HW_Test --> SysInt

5.1 ISO 26262 구조와 V-모델의 매핑

ISO 26262는 전체 12개 파트로 구성되어 있으며, 그중 시스템 개발의 핵심인 파트 3, 4, 5, 6은 V-모델의 흐름을 정확히 따른다.25

Part 3: 개념 단계 (Concept Phase)
V-모델의 최상위 ’사용자 요구사항 분석’에 해당한다.
아이템 정의(Item Definition): 개발 대상 시스템을 정의한다.
HARA (Hazard Analysis and Risk Assessment): 잠재적 위험원을 분석하고 위험도를 평가하여 안전 목표(Safety Goal)를 설정한다. 이 안전 목표가 최상위 안전 요구사항이 된다.28
Part 4: 시스템 수준 제품 개발 (Product development at the system level)
V-모델의 ’시스템 요구사항 및 아키텍처’와 ‘시스템 통합 및 검증’ 단계를 포괄한다.
좌측: 안전 목표를 달성하기 위한 기술적 안전 요구사항(TSR)을 도출하고, 이를 하드웨어와 소프트웨어로 할당(Allocation)하는 시스템 아키텍처를 설계한다.23
우측: 하드웨어와 소프트웨어를 통합하고, 전체 시스템이 안전 요구사항을 만족하는지 검증(System Verification)하며, 실차 환경에서 안전성을 확인(Safety Validation)한다.29
Part 5 (하드웨어) & Part 6 (소프트웨어): 상세 개발
Part 4에서 분기된 하드웨어와 소프트웨어는 각각의 하위 V-모델을 형성한다.
Part 6 (소프트웨어): 소프트웨어 요구사항 분석 → 아키텍처 설계 → 유닛 설계 및 구현 → 유닛 테스트 → 통합 테스트 → 소프트웨어 안전 요구사항 검증으로 이어지는 구체적인 V-사이클을 규정한다.23

5.2 ASIL 등급에 따른 검증 강도 차별화

ISO 26262는 위험도에 따라 ASIL(Automotive Safety Integrity Level)을 A(최저)에서 D(최고)까지 분류한다. V-모델의 각 단계에서 수행해야 할 검증 방법은 이 ASIL 등급에 따라 엄격하게 차등 적용된다.19

검증 활동	ASIL A	ASIL B	ASIL C	ASIL D	비고
단위 테스트 커버리지	구문 커버리지 (Statement)	분기 커버리지 (Branch)	분기 커버리지	MC/DC (수정 조건/결정)	ASIL D는 매우 높은 수준의 코드 검증 요구
정적 분석	권장	권장	강력 권장	강력 권장	MISRA C 등 코딩 규칙 준수 필수
안전 분석 (FMEA/FMEDA)	정성적 분석	정성적 분석	정량적 분석	정량적 분석	ASIL C/D는 고장 확률을 수치로 증명해야 함
독립성 요구	자체 검증 가능	자체 검증 가능	독립적 검증인	독립적 검증인	ASIL D는 개발자와 독립된 제3자의 검증 필수

이처럼 ISO 26262 하에서 V-모델은 단순한 개발 절차가 아니라, 각 단계마다 ASIL 등급에 맞는 증거(Evidence)를 산출하여 안전성을 입증하는 법적 보호 수단이 된다.

6. 항공우주 산업에서의 V-모델: DO-178C와 ARP4754

항공우주 산업은 자동차보다 훨씬 이전부터 V-모델을 엄격하게 적용해 온 분야이다. 항공기 인증(Certification)은 엔지니어링 역사상 가장 까다로운 프로세스 중 하나이며, 여기서 V-모델은 DO-178C(소프트웨어)와 ARP4754A(시스템)라는 두 가지 축으로 구현된다.32

graph TD
%% 스타일
classDef arp fill:#e0f7fa,stroke:#006064,stroke-width:2px;
classDef do178 fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
classDef artifact fill:#fff,stroke:#333,stroke-dasharray: 5 5;

subgraph ARP4754 [ARP4754A: 항공기 및 시스템 개발 프로세스]
Air_Req[항공기 기능 요구사항]:::arp
Sys_Alloc[시스템 기능 할당]:::arp
Sys_Arch[시스템 아키텍처 개발]:::arp
Sys_Ver[시스템 검증]:::arp
end

subgraph DO178 [DO-178C: 소프트웨어 수명 주기 프로세스]
SW_Plan[SW 계획 프로세스 PSAC]:::do178
SW_Req[SW 요구사항 프로세스]:::do178
SW_Code[SW 코딩 및 통합]:::do178
SW_Ver[SW 검증 프로세스]:::do178

%% DO-178C 내부 피드백
SW_Ver -.->|문제 발견 시| SW_Req
end

%% 프로세스 간 상호작용
Air_Req --> Sys_Alloc
Sys_Alloc --> Sys_Arch

%% 시스템 -> SW 입력
Sys_Arch -->|입력: 시스템 요구사항| SW_Plan
SW_Plan --> SW_Req
SW_Req --> SW_Code
SW_Code --> SW_Ver

%% SW -> 시스템 출력
SW_Ver -->|출력: 실행 가능한 오브젝트 코드| Sys_Ver

%% 추적성 (Traceability)
Sys_Ver -.->|양방향 추적성| Sys_Arch
SW_Req -.->|양방향 추적성| Sys_Arch
SW_Ver -.->|구조적 커버리지 MC/DC| SW_Code

6.1 ARP4754A와 DO-178C의 계층적 V-모델

항공기 개발은 단일 V-모델이 아닌, 계층적으로 중첩된 V-모델 구조를 가진다.

ARP4754A (시스템 레벨): 항공기 전체(Aircraft) → 시스템(System) → 서브시스템(Subsystem)으로 이어지는 상위 V-모델을 관장한다. 여기서 시스템 요구사항이 정의되고 하드웨어와 소프트웨어로 기능이 할당된다.34
DO-178C (소프트웨어 레벨): ARP4754A에서 할당받은 소프트웨어 요구사항을 입력으로 하여 시작되는 하위 V-모델이다. 소프트웨어 계획 → 요구사항 → 설계 → 코딩 → 통합 → 검증의 사이클을 다룬다.35

6.2 DO-178C의 핵심: 목표 기반 검증과 추적성

DO-178C는 특정 개발 방법론을 강제하기보다는, 달성해야 할 **목표(Objectives)**를 제시하는 데 초점을 맞춘다. 그러나 그 목표들의 논리적 순서는 V-모델을 강력하게 시사한다.

소프트웨어 레벨(DAL)과 검증: 항공기 운항 안전에 미치는 영향에 따라 소프트웨어 레벨을 DAL A(재난적, Catastrophic)부터 DAL E(영향 없음)까지 분류한다.
구조적 커버리지(Structural Coverage): V-모델의 우측 검증 단계에서 코드 실행 범위를 측정하는 기준이다.
DAL A: 소스 코드의 모든 조건과 결정이 독립적으로 결과에 영향을 미치는지 확인하는 **MC/DC (Modified Condition/Decision Coverage)**를 요구한다.32 이는 매우 혹독한 검증 기준으로, V-모델의 상세 설계와 단위 테스트 단계가 얼마나 정밀하게 연결되어야 하는지를 보여준다.
DAL B: 결정 커버리지(Decision Coverage).
DAL C: 구문 커버리지(Statement Coverage).
양방향 추적성(Bi-directional Traceability): DO-178C의 가장 중요한 요구사항 중 하나는 상위 요구사항 ↔ 하위 요구사항 ↔ 소스 코드 ↔ 테스트 케이스 간의 완벽한 양방향 추적성이다.35 이는 V-모델의 좌측과 우측, 그리고 상위와 하위가 빈틈없이 매핑되어야 함을 의미하며, 인증 당국(FAA, EASA 등)이 가장 중점적으로 심사하는 항목이다.

7. 국방 및 인프라 시스템에서의 V-모델

국방 분야는 V-모델의 발원지이자, 가장 거대한 규모로 V-모델을 운용하는 영역이다.

graph TD
%% 스타일 정의
subgraph Tier1 ["Tier 1: 전체 무기 체계 (System of Systems)"]
T1_Req[체계 요구사항]:::tier1
T1_Arch[체계 아키텍처]:::tier1
T1_Integ[체계 통합 및 검증]:::tier1
T1_Accept[운영 시험 평가]:::tier1
end

subgraph Tier2 ["Tier 2: 하위 시스템 (예: 레이더, 통제기)"]
direction TB
T2_Req[서브시스템 요구사항]:::tier2
T2_Design[서브시스템 설계]:::tier2
T2_Integ[서브시스템 통합]:::tier2
T2_Ver[서브시스템 검증]:::tier2
end

subgraph Tier3 ["Tier 3: 구성품 (HW/SW)"]
direction TB
T3_Design[상세 설계]:::tier3
T3_Impl[구현/코딩]:::tier3
T3_Test[단위/모듈 테스트]:::tier3
end

%% 연결 관계 (V within V)
T1_Req --> T1_Arch

%% Tier 1의 아키텍처가 Tier 2의 V모델을 트리거함
T1_Arch -->|할당 Allocation| T2_Req

%% Tier 2 흐름
T2_Req --> T2_Design
T2_Design -->|할당 Allocation| T3_Design

%% Tier 3 흐름 (최하위 V)
T3_Design --> T3_Impl
T3_Impl --> T3_Test

%% 위로 통합 (Integration Upwards)
T3_Test -->|납품| T2_Integ
T2_Integ --> T2_Ver
T2_Ver -->|납품| T1_Integ

T1_Integ --> T1_Accept

%% 추적성 표시
T1_Accept -.->|Validation| T1_Req
T2_Ver -.->|Verification| T2_Req
T3_Test -.->|Verification| T3_Design

7.1 MIL-STD-499의 유산과 SoS

초기 MIL-STD-499에서 시작된 시스템 엔지니어링 프로세스는 현대의 ‘복합 체계(System of Systems, SoS)’ 환경에서 더욱 고도화되었다.9 미사일 방어 체계를 예로 들면, 전체 방어 시스템(Tier 1 V-모델) 하위에 레이더 시스템(Tier 2 V-모델), 요격 미사일 시스템(Tier 2 V-모델), 지휘 통제 시스템(Tier 2 V-모델)이 존재하며, 각 Tier 2 시스템은 다시 수많은 하드웨어/소프트웨어 구성품(Tier 3 V-모델)으로 분해된다.11

이러한 ‘V within V’ 구조에서 각 V-모델의 통합(Integration) 지점은 상위 V-모델의 구현(Implementation) 단계와 만난다. 국방 프로젝트에서의 V-모델은 단순한 개발 프로세스를 넘어, 수많은 협력 업체와 정부 기관 간의 책임 소재를 명확히 하고, 수십 년에 걸친 운영 및 유지보수(LCC: Life Cycle Cost)를 고려한 총체적 관리 도구로 활용된다.

ARP4754A(시스템 레벨)와 DO-178C(소프트웨어 레벨)의 엄격한 상호작용과 데이터 흐름

graph TD
%% 스타일
classDef arp fill:#e0f7fa,stroke:#006064,stroke-width:2px;
classDef do178 fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
classDef artifact fill:#fff,stroke:#333,stroke-dasharray: 5 5;

subgraph ARP4754 [ARP4754A: 항공기 및 시스템 개발 프로세스]
Air_Req[항공기 기능 요구사항]:::arp
Sys_Alloc[시스템 기능 할당]:::arp
Sys_Arch[시스템 아키텍처 개발]:::arp
Sys_Ver[시스템 검증]:::arp
end

subgraph DO178 [DO-178C: 소프트웨어 수명 주기 프로세스]
SW_Plan[SW 계획 프로세스 PSAC]:::do178
SW_Req[SW 요구사항 프로세스]:::do178
SW_Code[SW 코딩 및 통합]:::do178
SW_Ver[SW 검증 프로세스]:::do178

%% DO-178C 내부 피드백
SW_Ver -.->|문제 발견 시| SW_Req
end

%% 프로세스 간 상호작용
Air_Req --> Sys_Alloc
Sys_Alloc --> Sys_Arch

%% 시스템 -> SW 입력
Sys_Arch -->|입력: 시스템 요구사항| SW_Plan
SW_Plan --> SW_Req
SW_Req --> SW_Code
SW_Code --> SW_Ver

%% SW -> 시스템 출력
SW_Ver -->|출력: 실행 가능한 오브젝트 코드| Sys_Ver

%% 추적성 (Traceability)
Sys_Ver -.->|양방향 추적성| Sys_Arch
SW_Req -.->|양방향 추적성| Sys_Arch
SW_Ver -.->|구조적 커버리지 MC/DC| SW_Code

8. V-모델과 현대 개발 방법론의 충돌과 융합

소프트웨어 산업의 속도가 빨라지고 불확실성이 증대됨에 따라, 전통적인 V-모델은 그 경직성(Rigidity)으로 인해 비판을 받아왔다. 이에 대한 대안으로 등장한 애자일(Agile) 방법론과의 관계 설정은 현대 시스템 엔지니어링의 가장 뜨거운 화두이다.

graph TD
%% 스타일
classDef macro fill:#eceff1,stroke:#455a64,stroke-width:2px,stroke-dasharray: 5 5;
classDef micro fill:#fff3e0,stroke:#e65100,stroke-width:2px;
classDef ci fill:#e0f2f1,stroke:#00695c;

subgraph Macro_V ["거시적 V-모델 (Macro Cycle)"]
SysReq[시스템 요구사항 & 아키텍처]:::macro
SysRel[시스템 릴리즈 & 인수]:::macro
end

subgraph Micro_Cycles ["구현 단계의 반복적 개발 (Micro Cycles)"]
direction LR
Sprint1((스프린트 1)):::micro
Sprint2((스프린트 2)):::micro
Sprint3((스프린트 N)):::micro

SysReq --> Sprint1
Sprint1 --> Sprint2
Sprint2 --> Sprint3
Sprint3 --> SysRel

subgraph Inside_Sprint [스프린트 내부 활동]
Plan[계획] --> Design[상세설계]
Design --> Code[구현]
Code --> UnitTest[단위테스트]
UnitTest --> Review[리뷰]
end
end

subgraph CI_CD ["지속적 통합 및 검증 (CI/CD)"]
AutoTest[자동화된 빌드 및 테스트]:::ci
UnitTest -.-> AutoTest
AutoTest -.->|피드백| Code
end

%% 설명 연결
Sprint1 -.- Inside_Sprint

8.1 애자일(Agile)의 도전: 속도와 유연성

예측 가능성 vs 적응성: V-모델은 요구사항이 초기에 확정되고 변경이 적은 프로젝트에 최적화되어 있다. 이는 ’예측 가능성’과 ’문서화’를 중시한다.39 반면, 애자일은 요구사항의 지속적인 변경을 환영하며, 짧은 주기의 반복(Iteration)을 통해 작동하는 소프트웨어를 신속하게 내놓는 ’적응성’을 최우선으로 한다.41
고객 관여: V-모델에서 고객은 주로 시작(요구사항)과 끝(인수)에만 등장하지만, 애자일은 개발 전 과정에 걸쳐 고객과 협업한다.

8.2 하이브리드 접근: 애자일 V-모델 (Agile V)

현실적으로 자동차나 항공기 같은 하드웨어 중심의 안전 필수 시스템을 순수 애자일로 개발하는 것은 불가능에 가깝다. 하드웨어의 수정 비용은 막대하며, 안전 규제(ISO 26262, DO-178C)는 방대한 문서화와 사전 계획을 요구하기 때문이다. 따라서 두 방법론의 장점을 결합한 하이브리드 V-모델이 대세로 자리 잡고 있다.43

V 내의 반복 (Iterations within V): 전체적인 시스템 아키텍처와 안전 목표는 V-모델의 엄격함을 따라 정의한다(Macro-V). 그러나 하위 소프트웨어 컴포넌트 개발 단계(Micro-Cycle)에서는 스크럼(Scrum) 방식을 적용하여 2~4주 단위의 스프린트를 돌며 구현과 단위 테스트를 반복한다.
스프린트로서의 V (V as a Sprint): 각 스프린트를 하나의 작은 V-사이클로 간주한다. 즉, 스프린트 내에서 설계-구현-테스트를 모두 수행하여 ’잠재적으로 출시 가능한 제품 증분’을 만든다.46
지속적 통합(CI)과 V-모델: 애자일의 DevOps 및 CI/CD 파이프라인을 도입하여, V-모델 우측의 단위 테스트와 통합 테스트를 자동화한다. 이는 V-모델의 가장 큰 병목인 ‘지연된 피드백’ 문제를 해결하고, 코드가 변경될 때마다 즉각적인 검증을 가능하게 한다.43

9. 미래의 V-모델: MBSE와 디지털 트랜스포메이션

V-모델은 디지털 기술의 발전과 함께 그 형태와 운용 방식이 근본적으로 변화하고 있다.

graph LR
%% 스타일
classDef old fill:#ffebee,stroke:#b71c1c,stroke-width:1px;
classDef new fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px;
classDef db fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,shape:cylinder;

subgraph Past [과거: 문서 중심 V-모델]
Doc1[요구사항 문서 Word]:::old
Doc2[설계 문서 PPT/Excel]:::old
Doc3[테스트 문서 Excel]:::old

Doc1 -.->|수동 업데이트/불일치 위험| Doc2
Doc2 -.->|정보 유실| Doc3
Doc3 -.->|추적 어려움| Doc1
end

subgraph Future [미래: MBSE V-모델]
direction TB
SysModel[(통합 시스템 모델\nSingle Source of Truth)]:::db

View1[요구사항 뷰\nRequirement Diagram]:::new
View2[구조/아키텍처 뷰\nBDD/IBD]:::new
View3[동작/기능 뷰\nActivity/State]:::new
View4[검증/파라메트릭 뷰\nParametric]:::new

%% 모든 뷰는 모델을 바라봄
View1 <--> SysModel
View2 <--> SysModel
View3 <--> SysModel
View4 <--> SysModel
end

%% 전환 화살표
Past ==>|Digital Transformation| Future

9.1 모델 기반 시스템 엔지니어링 (MBSE)으로의 진화

전통적인 V-모델이 방대한 문서(Document-Centric)에 의존했다면, 미래의 V-모델은 모델(Model-Centric)이 그 자리를 대신한다. SysML(Systems Modeling Language)과 같은 도구를 사용하여 요구사항, 아키텍처, 검증 계획을 하나의 통합된 디지털 모델로 구축한다.34 이는 V-모델의 좌측과 우측의 일관성을 자동으로 유지해주며, 요구사항 변경 시 영향도를 즉각적으로 파악할 수 있게 해준다. DO-331 표준은 이미 항공 분야에서 MBSE를 공식적인 인증 수단으로 인정하고 있다.48

9.2 가상 검증(Virtual Validation)과 시프트 레프트(Shift-Left)

물리적 프로토타입이 나올 때까지 기다려야 했던 V-모델의 우측 단계를 획기적으로 앞당기는 기술들이 등장했다.

디지털 트윈(Digital Twin): 가상 공간에 시스템을 복제하여 시뮬레이션한다.
HILs (Hardware-in-the-Loop simulation): 실제 하드웨어 제어기를 가상 환경 모델과 연결하여 테스트한다.49
Shift-Left: 이러한 가상 검증 기술을 통해 V-모델의 우측에 있는 테스트 활동을 좌측(설계 및 구현 초기)으로 이동시킨다. 이는 결함을 조기에 발견하여 수정 비용을 획기적으로 낮추는 효과를 가져온다.50

10. 결론: 복잡성 통제를 위한 영원한 프레임워크

시스템 엔지니어링 V-모델은 반세기 전 태동한 이래, 인류가 만들어낸 가장 복잡하고 위험한 시스템들을 성공적으로 구현하는 데 핵심적인 역할을 수행해 왔다. 독일 IABG와 미국 방위 산업의 현장에서 탄생한 이 모델은 ’추적성’과 ’대칭성’이라는 강력한 논리를 바탕으로, 엔지니어들에게 “무엇을 만들 것인가“와 “어떻게 검증할 것인가“를 끊임없이 묻게 한다.

오늘날 애자일의 물결 속에서 V-모델의 경직성에 대한 비판도 존재하지만, ISO 26262나 DO-178C와 같은 안전 표준이 요구하는 엄격한 책임 추적성과 무결성 증명에 있어 V-모델을 대체할 수 있는 대안은 아직 없다. 오히려 V-모델은 하이브리드 애자일, MBSE, 디지털 트윈과 결합하며 더욱 유연하고 강력한 형태로 진화하고 있다.

결국 V-모델은 단순한 절차서가 아니다. 그것은 엔지니어링의 본질인 ’문제 해결의 논리적 구조’를 시각화한 것이며, 복잡성의 파도 속에서 길을 잃지 않게 해주는 나침반이다. 시스템 엔지니어는 V-모델을 도그마로 받아들이기보다, 프로젝트의 성격과 리스크에 맞춰 유연하게 적용하고 확장해야 할 지적 자산으로 활용해야 할 것이다.

11. 참고 자료

What is Systems Engineering - incose, https://www.incose.org/about-systems-engineering/what-is-systems-engineering
Jim Gottfried - History of Systems Engineering, https://sdincose.org/wp-content/uploads/2013/11/1-Jim-Gottfried-SE-History-for-INCOSE-Conf-2013_0.pdf
Systems Engineering Definition - incose, https://www.incose.org/about-systems-engineering/system-and-se-definitions/systems-engineering-definition
V-model - Wikipedia, https://en.wikipedia.org/wiki/V-model
V Model in Software Testing A Complete Guide for QA Professionals - H2K Infosys, https://www.h2kinfosys.com/blog/v-model-in-software-testing-a-complete-guide-for-qa-professionals/
V-model (software development) - Wikipedia, https://en.wikipedia.org/wiki/V-model_(software_development)
V-Model Software Development: A Comprehensive Insight, https://www.orientsoftware.com/blog/v-model-software-development/
MIL-STD-499 SYSTEM ENGINEERING MANAGEMENT - EverySpec, http://everyspec.com/MIL-STD/MIL-STD-0300-0499/MIL-STD-499_10376/
Systems Engineering Standards: A Summary - AcqNotes, https://www.acqnotes.com/Attachments/Systems%20Engineering%20Standards%20A%20Summary.pdf
MIL-STD-499 - Systems Engineering Management (USAF) - SE Goldmine, https://segoldmine.ppi-int.com/node/45238
Defense Acquisition Review Journal. Volume 17, Number 1, Issue 53 - DAU, https://www.dau.edu/sites/default/files/2024-07/No.%201%20Issue%2053.pdf
V-Model in Software Development: Complete Guide to Verification and Validation SDLC - Teaching Agile, https://teachingagile.com/sdlc/models/v-model
Software Validation vs. Verification: 7 Critical Differences Tech Leaders Must Know, https://fullscale.io/blog/software-validation-vs-verification/
The difference between verification and validation - with special focus on experienced based testing - YouTube, https://www.youtube.com/watch?v=PsME5Z-hhKE
Verification and Validation in Software Engineering - GeeksforGeeks, https://www.geeksforgeeks.org/software-engineering/software-engineering-verification-and-validation/
Differences between Verification and Validation in Systems Engineering | by Harshitha Veeramachaneni | Medium, https://medium.com/@hveerama06/differences-between-verification-and-validation-in-systems-engineering-fc1c60b01b49
ELI5 Verification vs Validation with examples : r/QualityAssurance - Reddit, https://www.reddit.com/r/QualityAssurance/comments/qcq6ro/eli5_verification_vs_validation_with_examples/
ISO 26262 Software Compliance in the Automotive Industry - Parasoft, https://www.parasoft.com/learning-center/iso-26262/what-is/
Software Verification and Validation for Automotive Functional Safety - LHP Engineering Solutions, https://www.lhpes.com/blog/software-verification-and-validation-for-automotive-functional-safety
Why Cold Testing Is Critical for Automotive Safety and Performance - Icemakers, https://www.icemakers.se/why-cold-testing-is-critical-for-automotive-safety-and-performance/
The BMW Group’s Energy and Environmental Test Centre., https://www.press.bmwgroup.com/usa/article/attachment/T0080738EN_US/121371
Verification and Validation Guide for Data-Driven Systems Engineering - SPEC Innovations, https://specinnovations.com/blog/verification-and-validation-guide-ddse
A quick guide to ISO 26262 - Feabhas, https://www.feabhas.com/sites/default/files/2016-06/A%20quick%20guide%20to%20ISO%2026262%5B1%5D_0_0.pdf
ISO 26262 - Wikipedia, https://en.wikipedia.org/wiki/ISO_26262
ISO 26262 Software Compliance in the Automotive Industry - Contact Us, https://alm.parasoft.com/hubfs/ISO26262-Software-Compliance-Automotive.pdf
INTERNATIONAL STANDARD ISO 26262-3, https://cdn.standards.iteh.ai/samples/51358/09fd0466fdeb4169a8827dfb11ab2f8d/ISO-26262-3-2011.pdf
draft international standard iso/dis 26262-3, https://d1.amobbs.com/bbs_upload782111/files_36/ourdev_618792BO7YQN.pdf
whitepaper - iso 26262 and the systems engineering v-model - SPEC Innovations, https://specinnovations.com/hubfs/ISO%2026262%20and%20the%20Systems%20Engineering%20V-Model%20Whitepaper.pdf
Automotive ISO 26262 Design and Verification Challenges - Agnisys, https://www.agnisys.com/blog/automotive-iso-26262-design-and-verification-challenges/
Leveraging Lessons Learned from Automotive Design Reliability and Functional Safety for Aerospace and Defense Applications - Synopsys, https://www.synopsys.com/content/dam/synopsys/events/gomactech-2022-snps-fusa.pdf
Software for Safety-Related Automotive Systems - ZVEI, https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2025/Januar/Best_Practice_Guideline_Software_for_Safety-Related_Automotive_Systems/Best-Practice-Guideline-Software-for-Safety-Related-Automotive-Systems_final.pdf
DO-178C Certification - Your Complete Verification Journey - LDRA, https://ldra.com/do-178/
Safety versus Security in Aviation, Comparing DO-178C with Security Standards, https://elib.dlr.de/133710/1/SafetyVersusSecurityStandards.pdf
What Is RTCA DO-178C? Overview & Compliance in Aerospace - Parasoft, https://www.parasoft.com/learning-center/do-178c/what-is/
DO-178C - Wikipedia, https://en.wikipedia.org/wiki/DO-178C
An introduction to DO-178C | Ansys Knowledge, https://innovationspace.ansys.com/knowledge/forums/topic/an-introduction-to-do-178c/
Complete Verification and Validation for DO-178C - Vector, https://cdn.vector.com/cms/content/know-how/aerospace/Documents/Complete_Verification_and_Validation_for_DO-178C.pdf
The systems engineering overview and process (from the Systems Engineering Management Guide, 1990) - NASA Technical Reports Server (NTRS), https://ntrs.nasa.gov/citations/19930015490
SDLC V-Model - Software Engineering - GeeksforGeeks, https://www.geeksforgeeks.org/software-engineering/software-engineering-sdlc-v-model/
AGILE vs V-MODEL vs WATERFALL: Software Development Methodology - Foreignerds, https://foreignerds.com/agile-vs-v-model-vs-waterfall-software-development-methodology/
Project management intro: Agile vs. waterfall methodologies - Atlassian, https://www.atlassian.com/agile/project-management/project-management-intro
V Model vs Agile: What are the major differences? - KnowledgeHut, https://www.knowledgehut.com/blog/agile/v-model-vs-agile
V-Model vs Agile Methodologies: Verification-Driven vs Collaboration-Driven Development, https://teachingagile.com/sdlc/comparisons/v-model-vs-agile
Hybrid Agile Methodology: Spiral, V-Model & More - Inflectra Corporation, https://www.inflectra.com/Solutions/Methodologies/Hybrid.aspx
(PDF) Zhivete Model - a Hybrid of V Model and Agile Scrum for Product Development, https://www.researchgate.net/publication/370020207_Zhivete_Model_-_a_Hybrid_of_V_Model_and_Agile_Scrum_for_Product_Development
Agile V-Model - digitalplaybook.org, https://aiotplaybook.org/index.php?title=Agile_V-Model
DO-178C SOFTWARE COMPLIANCE FOR AEROSPACE & DEFENSE - Parasoft, https://alm.parasoft.com/hubfs/ebook-DO-178C-Software-Compliance-Aerospace-Defense.pdf
CertiA360: Enhance Compliance Agility in Aerospace Software Development - arXiv, https://arxiv.org/html/2511.11550v1
ISO 26262 Compliance and process enhancements — VAPI 0.1.0 documentation, https://eclipse.dev/openvehicle-api/vapi_doc/development_process.html
Verification and Validation of Autonomous Systems - arXiv, https://arxiv.org/html/2411.13614v1
Verification and Validation According to ISO 26262: A Workflow to Facilitate the Development of High-Integrity Software - MathWorks, https://it.mathworks.com/content/dam/mathworks/tag-team/Objects/e/71300_1D-4.pdf
(Brief) History of Systems Engineering - incose, https://www.incose.org/about-systems-engineering/history-of-systems-engineering